public int cleanExpiredEntries() {
        long now = timeService.getCurrentTimeMillis();
        long lastCheck = lastExpired.get();

        if ((now - lastCheck) > expirationInterval && lastExpired.compareAndSet(lastCheck, now)) {
            int count = jdbcTemplate.update(deleteExpired, now);
            logger.debug("Expiring code sweeper complete, deleted {} entries.", count);
            return count;
        }

        return 0;
    }

lastExpired (line 58) is a shared AtomicLong that stores the last time cleanup ran.
Condition: cleanup is only allowed to run when (now - lastCheck) > expirationInterval (e.g. once per minute).
CAS: lastExpired.compareAndSet(lastCheck, now) means: “set lastExpired to now only if it still equals lastCheck.”
So:
Thread A and B both call cleanExpiredEntries() (e.g. from generateCode() in two tests).
Both read lastCheck = lastExpired.get() (e.g. 0 or an old timestamp).
For both, (now - lastCheck) > expirationInterval is true.
One thread (say A) runs compareAndSet(lastCheck, now) first → it succeeds, updates lastExpired to now, then runs jdbcTemplate.update(deleteExpired, now) and deletes expired rows.
Thread B then runs compareAndSet(lastCheck, now) → it fails, because lastExpired was already changed by A, so it’s no longer equal to lastCheck. So B does not run the DELETE and returns 0.
So “another thread won the CAS” = the other thread’s compareAndSet succeeded and did the cleanup; this thread’s compareAndSet failed, so this thread skips the delete. That’s why cleanup may not run in this thread: the design intentionally lets only one thread perform the throttled cleanup.